Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/[e-mail] _Wed Jan 20 18:01:56 1993.msg

Internet Message Format | 1994-01-24 | 5KB

Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA10167; Wed, 20 Jan 93 18:01:56 MET
Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA24644; Wed, 20 Jan 1993 18:17:20 +0100
Received: by www3.cern.ch (NX5.67c/NX3.0S)
    id AA05229; Wed, 20 Jan 93 18:16:21 +0100
Date: Wed, 20 Jan 93 18:16:21 +0100
From: Tim Berners-Lee <[e-mail]>
Message-Id: <[e-mail]>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: Dan Connolly <[e-mail]>
Subject: Re: QueryForms and Input tag
Cc: Dave_Raggett <[e-mail]>, [e-mail]
Reply-To: [e-mail]

A few unrelated points about this.

A. There is a whole standard, as yukky as SGML, on Electronic data
Intercahnge, meaning forms and form submission.  I know no more
except it looks like fortran backwards with no spaces.
But it might be interesting for a set of featuire to be supported.

B. I see a need for the definition os two things, a form to be filled
out 9containing field types and constraints), and a format for the
return of the field values. The latter is a structure of typed values
(parameters) plus a note of the method to be applied and the object
to which it is to be appllied. (I can see several different forms
providing the same structure, for example a simpler form with a lkot
of default values, and a separate one in French, all targetted at the
same object).

I don't think the form should contain a macro for generting a query
in an arbitrary language. That is too open-ended a function. I think
the server should be responsible for taking a structure of field
values and applying it to an object.

I'd like to see this generalised. In HTTP2, an object may allow a
large set of operations. For each operations, one ought to be able to
retrieve a form for filling out the parameters. The guts of this form
should be no less than a complete parameter definition for the
method. Of couse a general method returns a structure of results as
well (rather than always a document).

I  see the following scenario:

1.    user follows a link to an object, a flight description, say
2.    The flight object has in its HTTP2 Allowed: field the
    Method RESERVE. The client program doesn't understand this
    but sticks it in the menu.
3.    The users wants to reserve a seat, and pulls down "RESERVE"
    from the menu.
4.    The client asks the server for a [set of] form[s] for which
    describe the parameters to the RESERVE method. The user may
    have to pick one.
5.    The user fills in the form.  The methodname RESERVE and the
    uri of the object he is operating on are supplied by the
    client software.
6.    Parameters (structure of field contents) , methodname and
    object uri are sent off to the server.
7.    A document is returned with the results.

The important thing is that we bridge the gap between automatic and
manual procedures. Obviously, the user will soon be making local
macros to reserve sets of flights for himself and his friends. So the
guts of what goes on must be machine-understandable, not just
human-readable.

Currently HTTP2 returns a MIME document. A MIME document can be a set
of objects each with a Content-Type,  but it is kinda heavy for an
array of 3 integers!  At this point, ASN/1 would seem a better bet (a
rare thing! ;-) Perhaps we can look at a multipart message and a data
structure in the same way with generality.

[A problem with including a more compact representation as part of a
MIME document is that MIME doesn't like encoding techniques to be
applied which hide the internal types from a MIME gateway. Therefore,
one might just have to say there was a black box MIME object like

    Content-Type: application/ASN-1
    Content-encoding: base64

Of course ASN/1 like SGML requires a reference to the DTD equivalent
for the (numeric in this case) tag values.  What a plethora of choice
we have with SGML, ASN/1, RCC822... Perhaps we can write
architectural forms for DTDs which produce ASN/1-equivalent
definitions, which will then allow the DTD to define the ASN/1 and
ASN/1 to become a natural alternative syntax for any conforming DTD.
[It could (is?) done now, but the architectural forms would allow a
field which is in fact an integer to be sent as an ASn/1 integer
rather than as a bit of text]

In fact of course the form itself in fact contains a specification of
the type of the field value structure, so from the form one can
generate the DTD and/or ASN/1 description for the reply ... silly me.
In fact one can imagine the output data coming in the same way, as a
set of field values plus a set of forms which would allow its display
in various languages etc.  The specification of a method required
just giving the URIs of the infput and output forms.

At any rate, I think it is important to differentiate the set of
values from the form.

Tim